T1: extend canary oracle with 8814AU path-C/D BB regs#72
Merged
Conversation
The original `DEVOURER_DUMP_CANARY` set was 8812AU-specific — covered path A/B BB regs (0xc**, 0xe**) plus shared MAC/RF regs. 8814AU has additional path C/D BB-table state at 0x18xx (path C) and 0x1Axx (path D) — the existing oracle silently skipped these on 8814AU, so any init drift in the path-C/D programming was invisible. Extends the dump: - `RadioManagementModule::phy_SwChnlAndSetBwMode8812` now appends the 8814AU path-C/D registers when `version_id.ICType == CHIP_8814A`. Covers TX-AGC (0x1820-0x1840 / 0x1a20-0x1a40), BB-swing (0x181c / 0x1a1c), and IGI (0x1850 / 0x1a50). - RF[C] / RF[D] are intentionally skipped — paths C/D RF are write-only by HW design on 8814AU (kaeru cite "RTL8814AU RF read mechanism — paths C/D write-only by HW design"). Read attempts return undefined data so there's no useful canary surface there. - `tools/canary_kernel_dump.sh` takes an optional third `chip` argument (default `8812`). With `chip=8814`, dumps the same path-C/D set so the kernel + devourer captures are comparable line-by-line. Surfaced divergences (8814AU, ch6, fresh capture vs aircrack-ng /88XXau in VM): - 8 BB-AGC anchor regs differ (0x80c, 0x82c, 0x830, 0x834, 0x8ac, 0x8b0, 0x8c4, 0xe90). - 7 MAC anchor regs differ (0x040, 0x100, 0x420, 0x4c8, 0x522, 0x610, 0x614). - Path-C/D BB-swing (0x181c / 0x1a1c) at 5G — kernel writes 0x2D400053 (band-set), devourer leaves BB-init 0x40000053. - Path-C/D IGI (0x1850 / 0x1a50) — kernel 0x22 vs devourer 0x20 on 5G; DIG floor doesn't apply to 8814 path-C/D in devourer. - REG_MACID @ 0x610/0x614 = 0 on devourer (EFUSE port from prior T1 work fires for 8812/8821 but not 8814 — different EFUSE offset). Each of these is a separate follow-on fix; this PR is just the oracle plumbing so future 8814 init-correctness work has visible ground truth to chase. The current dump output is purely diagnostic — no functional behaviour change on any chip. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The original
DEVOURER_DUMP_CANARYset was 8812AU-specific — covered path A/B BB regs (0xc**,0xe**) plus shared MAC/RF regs. 8814AU has additional path-C/D BB-table state at0x18xx(path C) and0x1Axx(path D); the existing oracle silently skipped these on 8814AU, so any init drift in path-C/D programming was invisible.Extension
RadioManagementModule::phy_SwChnlAndSetBwMode8812now appends the 8814AU path-C/D registers whenversion_id.ICType == CHIP_8814A. Covers TX-AGC (0x1820-0x1840/0x1a20-0x1a40), BB-swing (0x181c/0x1a1c), and IGI (0x1850/0x1a50).tools/canary_kernel_dump.shtakes an optional thirdchipargument (default8812). Withchip=8814, dumps the same path-C/D set so the kernel + devourer captures are comparable line-by-line.Divergences this oracle surfaces (8814AU, ch6, fresh capture vs aircrack-ng/88XXau)
8 BB-AGC anchor regs (
0x80c,0x82c,0x830,0x834,0x8ac,0x8b0,0x8c4,0xe90), 7 MAC anchor regs (0x040,0x100,0x420,0x4c8,0x522,0x610,0x614), and 4 path-C/D BB regs (0x181c,0x1a1c,0x1850,0x1a50). At 5G additionally: BB-swing on path-C/D doesn't get the band-set write (devourer leaves BB-init default; kernel writes0x2D400053). REG_MACID at0x610is zero on devourer (the EFUSE port from prior T1 work fires for 8812/8821 but not 8814 — different EFUSE offset).Test plan
DEVOURER_DUMP_CANARY=1on 8814AU outputs the path-C/D extension after the standard set.tools/canary_kernel_dump.sh wlx... 6 8814outputs the symmetric kernel-side dump.DEVOURER_DUMP_CANARY=1is set.Follow-on
Each surfaced divergence is a separate fix candidate (REG_MACID for 8814, path-C/D BB-swing band-set, etc.). This PR just lays the ground truth so those fixes can be verified against a working oracle instead of blind reading.
🤖 Generated with Claude Code